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ABSTRACT 

Shiptracks  are  known  to  be  a  relatively  common  phenomenon,  often  appearing  in 
AVHRR  channel  3  imagery  as  anomalous,  curvilinear  cloud  lines.  Despite  their 
significance  to  remote  ship  surveillance  studies,  the  formation  mechanisms  responsible 
for  shiptrack  production  are  still  largely  unknown  and  their  specific  characteristics  still 
undefined. 

A  shiptrack  detection  algorithm  being  developed  at  the  Naval  Postgraduate  School 
seeks  to  objectively  detect  and  locate  shiptracks  on  AVHRR  imagery.  This  algorithm  is  a 
major  step  in  objectively  defining  specific  shiptrack  characteristics  and  automating  the 
search  for  additional  shiptrack  examples.  The  purpose  of  this  study  was  to  outline  the 
logic  of  the  detection  algorithm  and  present  a  subjective  performance  summary  of  its 
usefulness. 

After  careful  analysis  of  the  algorithm  output  files  on  several  full  satellite  passes,  it 
was  determined  that  the  algorithm  is  capable  of  successfully  detecting  up  to  65%  of  the 
fresh  shiptracks  within  a  full  pass  AVHRR  image  with  a  false  detection  rate  of  only  1.31 
tracks  per  million  square  kilometers.  This  performance  is  likely  to  improve  further  with 
continued  work  focused  on  designing  adequate  filters  to  categorically  reject  many  of  the 
recurring  false  detections. 
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I.    INTRODUCTION 

A.  BACKGROUND 

Anomalous  cloud  lines  were  first  recognized  in  the  summer  of  1965  from  a 

TEROS-IV  (visible)  satellite  image  southeast  of  the  Kuril  Islands.  The  image  showed 
three  long,  plume-like  cloud  lines  that  crossed  a  large-scale  cloud  pattern  at  high  angles, 
the  longest  of  the  cloud  lines  being  350  km  long  and  5  to  24  km  wide.  Careful  inspection 
of  the  image  suggested  that  the  cloud  lines  were  at  an  altitude  near  that  of  the  large-scale 
band  of  clouds  and  were  probably  warmer  than  freezing.  It  was  further  suggested  that 
their  origin  was  anthropagenic,  with  possible  sources  given  as  stationary  ships  such  as 
whaling  vessels  or  factory  ships  that  released  large  quantities  of  water  vapor  as  they 
processed  their  catch  at  sea  (Conover,  1966). 

After  conducting  an  exhaustive  search  for  additional  anomalous  cloud  line  images, 
Conover  published  his  conclusions  on  anomalous  cloud  line  formation  mechanisms  based 
on  the  16  known  cases  to  date.  He  concluded  that  "the  most  likely  cause  of  the  cloud 
lines  stems  from  exhaust  from  ocean  going  vessels.  Large  numbers  of  Aitken  nuclei 
form  in  this  exhaust.  These  are  carried  upward  by  the  buoyancy  of  the  hot  gasses  and 
"ship's  air  wake"  to  form  droplets  at  slight  super-saturation.  This  phenomenon  does  not 
appear  related  to  special  characteristics  of  the  vessels  power  plant  but  to  a  critical 
condition  of  the  atmosphere." 

This  early  work  demonstrated  that  under  certain  atmospheric  conditions,  the  exhaust 

from  ocean  going  vessels  can  result  in  the  formation  of  anomalous  cloud  lines  visible 
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from  space  in  the  visible  wavelengths.  It  wasn't  until  1987  however,  when  it  was 
discovered  that  these  same  mechanisms  produced  similar  cloud  lines  in  pre-existing 
marine  stratus  clouds  in  the  near  infrared  (3.7  u.m),  that  the  shiptrack  phenomenon  began 
to  generate  great  interest  from  climatologists  and  more  recently,  leaders  in  Naval 
Intelligence. 

This  increased  interest  began  when  Coakley  et  al  (1987)  first  described  the  shiptrack 
phenomenon  based  on  observations  made  with  NOAA  Advanced  Very  High  Resolution 
Radiometer  (AVHRR)  in  the  near-infrared  and  continued  on  into  1991  when  a  frequency 
of  occurrence  study  off  of  the  West  Coast  of  the  United  States  suggested  that  the 
phenomenon  is  relatively  common  in  this  high  ship  traffic  density  region,  especially 
during  the  summer  months  (Durkee  and  Lutz,  1991).  Coakley  et  al.  observed  that  under 
stable  meteorological  conditions  the  effect  of  ship-stack  exhaust  on  overlying  marine 
stratus  clouds  is  to  increase  the  number  of  cloud  droplets  while  decreasing  the  cloud 
droplet  size,  resulting  in  an  increase  in  the  reflectance  of  the  cloud  at  3.7  jini  (and  to  a 
lesser  extent  0.63  )im).  Remote  and  in-situ  measurements  of  shiptrack  modified  clouds 
made  by  Radke  et  al  (1989)  and  Hindman  et  al  (1990)  indicate  that  the  shiptracks  contain 
a  higher  number  of  smaller  cloud  droplets  and  an  increased  liquid  water  content  than  the 
surrounding  ambient  cloud. 


B.  MOTIVATION 

The  formation  mechanisms  that  produce  shiptracks  at  sea  are  still  not  completely 
understood.  Yet,  when  one  looks  at  the  effects  that  man-made  aerosols  have  on  the 
global  climate,  the  shiptrack  phenomenon  may  represent  an  effect  several  times  more 
influential  in  modifying  the  local  radiation  budget  than  that  of  direct  interaction  of  solar 
radiation  with  the  ship  produced  aerosol  particles  themselves  (Coakley  et  al,  1987).  A 
thorough  understanding  of  the  effects  of  man-made  aerosols  on  the  reflectance  of 
pre-existing  clouds  and  their  associated  effects  on  the  radiation  budget  is  fundamental  in 
completely  understanding  the  effects  of  increasing  levels  of  man-made  aerosol  emissions 
into  the  atmosphere.  Essential  to  this  understanding,  and  a  logical  place  to  focus  the 
study,  is  in  detenmning  the  necessary  atmospheric  conditions  and  formation  mechanisms 
that  produce  shiptracks. 

Shiptracks  generally  appear  in  near-infrared  (near-IR)  imagery,  centered  at  3.7  \im,  as 
bright,  curvilinear  anomalies  within  marine  stratiform  clouds  (Fig.  1).  They  tend  to 
maintain  a  fairly  constant  width  and  brightness  despite  their  persistence  over  several 
hundreds  of  kilometers.  They  range  in  width  from  roughly  7  to  10  km  near  their  head 
and  up  to  25  km  towards  their  trailing  ends.  In  visible  (VIS)  imagery,  centered  at 
0.63  jim,  the  same  shiptracks  do  not  always  stand  out,  often  appearing  only  slightly 
brighter  than  the  surrounding  cloud  (Fig.  2).  Finally,  in  infrared  imagery  (TR),  centered  at 
1 1.0  u.m,  shiptracks  do  not  appear  at  all.  Cloud  regions  where  shiptracks  are  known  to  be 
appear  simply  as  ordinary  medium  to  low  level  stratiform  clouds  in  the  infrared  (Fig.  3). 


Figure  t.  AVIIRR  channel  3  image  taken  by  NOAA-9  on  July  13,  1987 


Figure  2.  AVHRR  channel  1  image  taken  by  N'OAA-9  on  July  13,  1987 


Figure  3.  AVHRR  channel  4  image  Liken  by  NOAA-9  on  July  13,  1987 


The  shiptrack  phenomenon  is  of  particular  interest  to  the  Navy  for  its  potential 
applications  in  remote  ship  surveillance.  Until  recently,  potential  enemy  battle  group 
movements  could  be  detected  from  space  only  during  daylight  hours  and  under  clear 
skies.  Because  shiptracks  can  be  seen  in  marine  stratus  clouds  in  the  near-infrared,  they 
present  an  opportunity  to  fill  in  some  of  the  time  and  area  gaps  in  relocating  a  battle 
group  lost  under  cloud  cover.  With  the  present  technology  shiptracks  can  only  be  used  to 
approximate  ship  traffic  density,  individual  ship  positions  and  their  relative  courses  and 
speeds.  It  is  hoped  that  a  thorough  study  of  shiptracks  will  reveal  an  exploitable,  long 
range,  detection  method  for  certain  ship  classes  (i.e.  size  and/or  powerplant)  along  with 
possible  counter-detection  procedures  for  our  own  forces. 

C.  OBJECTIVES 

Shiptracks,  like  all  cloud  features,  are  extremely  diverse.    Distinguishing  a  shiptrack 
from  the  surrounding  cloud  feamres  can  often  be  very  subjective,  especially  in  regions 
where  the  clouds  have  naturally  occurring  sharp,  linear  features.  It  becomes  more 
difficult  to  follow  a  shiptrack  further  away  from  its  head.  This  subjectivity  emphasizes 
the  need  to  objectively  define  and  locate  shiptracks  using  characteristics  of  the  image  in 
the  visible,  near-infrared  and  infrared  wavelengths.  Removing  the  subjectivity  in  finding 
shiptracks  is  the  first  step  in  systematically  analyzing  and  understanding  shiptracks. 

A  second  problem  facing  researchers  is  the  time  required  to  sift  through  the  enormous 
quantity  of  satellite  tapes  to  find  a  statistically  valid  number  of  shiptracks  in  which  to 
base  a  smdy.  Currently,  an  AVHRR  satellite  pass  takes  about  20  minutes  to  process 


before  it  can  be  viewed.  In  order  to  get  the  resolution  necessary  to  adequately  see 
shiptrack  feahires,  the  image  must  be  blown-up  (painted)  frame  by  frame,  often  taking  up 
to  several  hours  to  manually  scan  the  entire  image. 

The  most  efficient  way  to  objectively  locate  shiptracks  on  satellite  images  is  by  using 
a  computer  based  shiptrack  detection  algorithm  that  can  scan  an  entire  satellite  pass  and 
use  specific,  known  characteristics  of  shiptracks  to  distinguish  the  shiptracks  from  the 
surrounding  cloud.  One  such  algorithm  is  being  developed  here  at  the  Naval 
Postgraduate  School  by  Kurt  Nielsen  (under  the  direction  of  Professor  Phil  Durkee).  It  is 
the  objective  of  this  thesis  to:  1)  Outline  the  logic  and  various  optional  control  parameter 
settings  found  in  the  current  shiptrack  detection  algorithm,  2)  Empirically  determine  the 
most  efficient  option  settings  of  the  algorithm  based  on  a  single,  multiple-ship  track 
satellite  image  and,  3)  Present  a  performance  summary  of  the  algorithm  on  several 
AVHRR  images. 


II.  SATELLITE  DATA  COLLECTION  AND  PROCESSING 

The  shiptrack  detection  algorithm  is  designed  to  work  on  Advanced  Very  High 
Resolution  Radiometer  (AVHRR),  High  Resolution  Picture  Transmission  (HRPT), 
images  taken  from  the  National  Oceanic  and  Atmospheric  Administration  (NOAA)  polar 
orbiting  satellites.  The  data  stream  is  typically  archived  on  standard  9-track  magnetic 
tapes,  each  of  which  hold  up  to  7  minutes  of  data.  Satellite  images  are  processed  from 
the  raw  data  in  the  U.S.  Naval  Postgraduate  School's  Interactive  Digital  Environmental 
Analysis  (IDEA)  laboratory  by  a  network  of  VAX  8250  computers.  Once  processed,  the 
shiptrack  detection  algorithm  can  be  run  and  the  image  viewed  in  full  (at  a  reduced 
resolution)  orin512x512  pixel  blocks  (at  full  resolution). 

A.  SATELLITE 

The  current  Polar  Orbiting  Operational  Environmental  Satellite  (POES)  flown  by 
NOAA  is  the  Advanced  TEROS-N  (ATN).    The  satellites  themselves,  two  of  which  are 
flying  at  any  given  time,  are  in  Sun-synchronous,  circular  orbits  at  altitudes  of 
approximately  850  km.  Under  normal  conditions,  one  satellite  will  be  in  an  orbit  with  a 
southbound  equator  crossing  time  at  about  0730  local  solar  time  (LST),  the  other  with  a 
northbound  equator  crossing  time  at  about  1430  LST.  These  orbits  are  selected  to 
provide  maximum  global  coverage  within  the  limitations  imposed  by  the  communications 
and  data  handling  facilities  and  the  time-lines  needs  of  data  users  (Rao  et  al,  1990). 


The  primary  POES  mission  is  to  provide  daily  global  observations  of  weather 
patterns  and  environmental  conditions  in  the  form  of  quantitative  data  usable  for 
numerical  weather  analysis  and  prediction.  POES  spacecraft  are  used  to  observe  and 
derive  cloud  cover,  ice  and  snow  coverage,  surface  temperatures,  vertical  temperature  and 
humidity  profiles. 

B.  SENSOR 

The  AVHRR  is  a  scanning  radiometer  carried  by  the  ATN  that  is  sensitive  to  the  VTS 
and  near-IR,  and  IR  "window"  regions.  Data  is  retained  from  a  swath  extending  55.4 
degrees  to  either  side  of  nadir  (2048  pixels  per  scan  per  channel)  having  a  resolution  of 
1.1  km  directly  below  the  satellite.  The  sensor  records  the  Earth's  radiation  in  five 
wavelengths,  one  in  the  visible,  one  in  the  near- visible  and  three  in  the  infrared  (Table  1). 
The  data  is  transmitted  to  ground  stations  for  distribution  as  1 . 1  km  resolution,  High 
Resolution  Picture  Transmission  (HRPT)  data.  Of  particular  interest  to  this  study  are  the 
visible,  near-infrared  and  thermal  infrared  HRPT  data,  (AVHRR  channels  1 ,  3  and  4 
respectively). 
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C.  CHANNELS  USED 

In  general,  shiptracks  are  best  seen  in  the  near-ER  channel  3  imagery.  It  is  in  this 
channel  that  all  of  the  searching  by  the  shiptrack  detection  algorithm  for  potential 
shiptracks  occures.    This  channel  is  calibrated  in  units  of  radiance.  Because  channel  3  is 
in  the  near-IR,  the  daylight  radiance  observed  from  the  satellite  has  contributions  from 
both  solar  reflectance  and  thermal  emission.  By  utilizing  a  method  described  by  Allen 
(1987),  the  thermal  emission  portion  of  the  total  radiance  at  this  wavelength  can  be 
subtracted  out  leaving  only  the  reflected  contribution.  In  this  study,  both  types  of  channel 
3  data  are  used  and  will  be  referred  to  as  simply  channel  3  data  (solar  reflectance  and 
thermal  emission)  and  Low3  (solar  reflectance  only). 

The  shiptrack  detection  algorithm  uses  data  from  channel  1(VIS)  in  various  filter  tests 
(which  will  be  described  in  more  detail  in  chapter  3)  to  help  reject  natural  features  which 
may  look  like  shiptracks  in  channel  3  imagery.  The  data  is  calibrated  in  terms  of  albedo 
and  is  converted  to  units  of  percent  reflectance.  This  conversion  is  based  on  weighting 
the  received  reflectance  by  the  cosine  of  the  solar  zenith  angle  and  the  anisotropic 
reflectance  factor  (Allen,  1987). 

The  algorithm  uses  channel  4  (IR)  data  in  much  the  same  way  it  uses  the  channel  1 
data.  The  data  is  the  result  of  thermal  emission  and  is  converted  to  a  radiance 
measurement  with  units  of  radiance  by  using  a  linear  correlation  to  counts. 
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TABLE  1 

AVHRR  CHANNELS 

CENTER 

CHANNEL  WAVELENGT                  ,VAV 

PRIMARY  USES 

1 

0.58-0.68 

0.63 

Daytime  cloud/surface 
mapping 

2 

0.725-1.10 

0.83 

Surface  water  delineation, 
ice  and  snow  melt 

3 

3.55-3.93 

3.70 

Sea  surface  temperature, 
night-time  cloud  mapping 

4 

10.30-11.30 

11.00 

Sea  surface  temperature, 
day/night  cloud  mapping 

5 

11.50-12.50 

12.00 

Sea  surface  temperature, 
day/night  cloud  mapping 
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III.     SfflPTRACK  DETECTION  ALGORITHM 

The  goal  of  this  chapter  is  to  outline  the  processing  steps,  the  detection  logic  and  the 
sub-programs  used  to  detect  shiptracks.  The  shiptrack  detection  algorithm  processes  a 
full-pass  AVHRR  satellite  image,  using  channel  1 ,  3  and  4  data  to  objectively  locate 
shiptracks.  The  algorithm  uses  three  (2048  x  N  pixels)  files  containing  the  channel  1 ,  3 
and  4  data  as  inputs  and  returns  a  corresponding  summary  output  file  containing  locations 
in  the  image  where  possible  shiptracks  can  be  found.  The  input  files  must  be  created 
using  a  program  utility  (called  Datadump),  which  converts  the  individual  channel  data 
from  the  satellite  tapes  to  real  data  files,  and  a  program  (called  reaHbyte)  which  then 
converts  the  real  data  files  to  a  fixed  record  length  byte  file  format  that  the  algorithm  can 
accept.  The  output  file  can  be  viewed  directly  by  the  user  after  it  has  been  condensed  to  a 
512x512  fixed  record  length  file  (using  a  program  called  fixcondO).  Once  a  satellite 
pass  is  loaded  and  processed,  the  steps  taken  to  produce  an  output  file  can  eventually 
become  automated.  This  will  allow  the  user  to  select  a  satellite  pass  overview,  initiate  the 
program,  and  come  back  several  hours  later  to  observe  the  results. 

The  detection  code  is  composed  of  13  separate  modules  which  utilize  20  control 
parameters.  This  rather  large  computer  program  is  required  to  do  objectively  what  the 
human  eye  can  do  (albeit  somewhat  subjectively)  at  a  glance.  Shiptracks  often  stand  out 
from  their  surroundings  in  channel  3  imagery  as  being  long,  curvilinear  features  of  sharp 
contrasting  brightness.  Because  the  human  eye  can  view  an  entire  image  at  once,  it  is 
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able  to  fill  in  small  gaps  in  the  linearity  where  the  shiptrack  contrast  with  the  surrounding 
cloud  diminishes.  With  the  present  technology,  it  is  not  possible  to  reproduce  what  the 
eye  can  do  so  a  rather  complicated  algorithm  is  required  to  enable  a  computer  to  detect 
shiptracks  while  only  being  able  to  process  small  sections  of  the  image  at  a  time. 

A.  THE  LOGIC 

The  core  of  the  program  is  a  main  do-loop  which  calls  the  13  subroutines.  Of  these 
subroutines,  5  are  a<hninistrative,  dealing  with  such  things  as  loading  and  manipulating 
the  images  and  inputting  the  various  control  parameters,  while  the  remaining  8  do  most  of 
the  detection  work.  These  8  subroutines  focus  on  detecting  various  generic  shiptrack 
characteristics  and  ultimately  pass  their  findings  back  to  the  administrative  subroutines 
which  record  a  shiptrack  image  onto  a  giant  output  image  file.  Due  to  memory 
limitations  of  the  VAX  computer,  a  main  do-loop  must  break  down  the  giant  input 
images  into  512x512  area  images  (hereafter  referred  to  as  block  images)  and  feeds  them 
one  at  a  time  to  the  subroutines  for  analysis.  A  shiptrack  image  file  is  created  for  each  of 
the  block  images  by  the  subroutines  and  passed  back  to  the  main  program.  A  final 
subroutine  is  then  called  which  maps  the  shiptrack  image  onto  a  giant  output  image  file. 
This  loop  repeats  itself  until  the  entire  giant  input  image  is  processed. 

A  detailed  presentation  of  the  algorithm  logic  is  best  handled  by  analyzing  each 
subroutine  separately  in  the  order  in  which  it  is  called  by  the  main  program.  Since 
shiptracks  are  like  long  cloud  "roads",  construction  terms  are  used  to  describe  each 
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subroutine  within  the  automated  detection  algorithm.  The  first  call  is  to  the  subroutine 
Foreman  which  loads  the  user-selected  control  parameters  into  memory  for  use  by  me 
remaining  subroutines  inside  the  main  do-loop.  Once  these  settings  are  loaded,  the 
program  enters  the  main  do-loop  where  the  remaining  subroutines  are  called  to  detect 
shiptracks  and  record  their  findings  in  the  output  file  (Fig.  4). 

1.  Foreman 

This  subroutine  finds  and  loads  the  20  control  parameters  which  are  stored  in  a 
separate  list  file  for  easy  manipulation.  The  parameters  are  listed  in  Table  2  along  with 
the  subroutine  in  which  they  are  called  and  typical  values  of  each  parameter.  Each  of  the 
parameters  will  be  described  in  detail  when  the  appropriate  subroutine  is  discussed. 

2.  Getimg  1,  Getimg3,  Getimg4 

These  subroutines  read  in  block  images  from  the  giant  channel  1 ,  3  and  4  byte  files 
and  map  them  into  corresponding  block  files  called  IMG1,  IMG3  and  IMG4  respectively. 
Getimg3  performs  a  conversion  of  the  IMG3  data  from  byte  to  integer,  resulting  in  a  two 
dimensional  array  of  integer  channel  3  brightness  values.  IMG1  and  IMG4  are  initially 
left  as  byte  arrays,  which  take  up  only  1/4  of  the  space  of  a  corresponding  integer  array, 
and  can  be  stored  in  this  compact  form  until  needed. 
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Figure  4.  Shiptrack  Detection  Algorithm  Main  Do-Loop 
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TABLE  2 

CONTROL  PARAMETERS  CALLED 

IN  SUBROUTINE  FOREMAN 


NAME        SUBROUTINE     TYPICAL  VALUE 


FACT 

CENSUS 

1.4 

STDMIN 

CENSUS 

5 

TLOW 

CENSUS 

273 

THIGH 

CENSUS 

299 

CUTOFF 

NEIGHBORHOOD 

8 

RADIUS 

ROADWAY 

50 

THRESH3(1) 

PAVE 

1 

THRESH3(2) 

PAVE 

8 

THRESH3(3) 

PAVE 

88 

PATHRESH 

PAVE 

80 

PATHGRAD 

LANDSCAPE 

8 

THRESH3WD 

LANDSCAPE 

80 

GRAV1 

GRAVEL 

70 

GRAV2 

GRAVEL 

25 

GRAV3 

GRAVEL 

10 

GRAV4 

GRAVEL 

10 

BOGUS  1 

GRAVEL 

60 

BOGUS2 

GRAVEL 

60 

BOGUS5 

GRAVEL 

50 

BOGUS6 

GRAVEL 

10 
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Conversion  of  the  whole  IMG3  array  is  done  because  the  algorithm  scans  the  entire 
channel  3  image  looking  for  potential  shiptrack  features  and  requires  channel  3  brightness 
counts  (in  integer  form)  for  its  initial  search.  The  IMG1  and  IMG4  array  data  are  used  in 
subsequent  subroutine  checks  on  prospective  shiptrack  features  and  are  converted  to 
integer  form  as  needed. 

3.  Census 

Census  examines  the  IMG3  data  and  maps  each  pixel  that  exceeds  certain  brightness 
and  temperature  thresholds  into  an  initially  null  giant  working  array  (IMGO)  as  a  code  1 . 
Specifically  the  subroutine  breaks  the  channel  3  block  image  up  into  16x16  subareas  and 
computes  the  mean  and  standard  deviation  for  each.  It  then  converts  the  corresponding 
subarea  portion  of  the  IMG4  array  to  integer  form  and  calculates  the  temperature  of  each 
pixel.  Provided  the  subarea  has  a  sufficient  variation  in  channel  3  pixel  brightness 
(subarea  standard  deviation  greater  than  Stdmiri),  each  pixel  within  that  subarea  which  has 
a  channel  3  brightness  count  greater  than  the  control  parameter  fact  multiplied  by  the 
subarea  standard  deviation  and  a  temperature  within  Tlow  and  Thigh,  is  flagged,  and  its 
position  mapped  as  a  code  1  in  the  working  array.  If  the  subarea  standard  deviation  is 
below  the  control  parameter  Stdmin,  the  entire  subarea  is  mapped  as  0*s  in  the  working 
array. 
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4.  Neighborhood 

The  neighborhood  subroutine  is  designed  to  screen  the  "bright"  pixels  found  in 
Census  for  randomness.  Shiptracks  tend  to  be  long,  linear,  bright  features  in  channel  3. 
If  the  "bright"  pixels  found  in  Census  are  randomly  dispersed  (ie,  do  not  form  linear 
patterns),  they  are  likely  not  part  of  a  shiptrack. 

The  subroutine  breaks  the  working  array  (IMGO)  into  16x16  subareas  and  counts 
each  code  1  pixel.  A  separate  16x16  "neighborhood"  array  is  created  that  maps  the 
number  of  code  1  pixels  located  within  +/-  2  pixel  lengths  from  each  pixel  location  in  the 
IMGO  array.  Pixels  in  IMGO  that  have  a  corresponding  "neighborhood"  count  in  the 
neighborhood  array  that  is  greater  than  Cutoff 'are  flagged  and  re-mapped  as  code  2's  back 
in  IMGO.  This  procedure  ensures  that  only  sufficiently  "clumpy"  bright  areas  are 
considered  as  potential  shiptrack  elements  as  opposed  to  randomly  distributed  bright 
pixels. 

Finally  a  neighborhood  representative  is  chosen  from  all  of  the  code  2's  within  each 
subarea  based  on  brightness.  The  brightest  code  2  pixel  within  the  subarea  is  flagged  and 
re-mapped  as  a  code  3  within  IMGO.  The  end  result  is  a  working  array  of  l's,  2's  and  3's, 
with  the  3's  being  the  essential  information  required  by  the  next  subroutine  called 
Roadway.     . 
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5.  Roadway 

The  objective  of  Roadway  is  to  analyze  path  segments  connecting  neighborhood 
representatives  to  determine  whether  the  segments  meet  certain  criteria  that  are 
characteristic  of  shiptracks.  The  subroutine  itself  calls  upon  5  of  the  remaining  6 
subroutines  and  all  (1 5)  of  the  remaining  control  parameters  used  in  the  algorithm.  Like 
Census  and  Neighborhood,  Roadway  uses  IMGO  as  the  working  array.  Possible 
shiptrack  path  segments  connecting  the  neighborhood  representative  (3's)  are  initially 
coded  as  4's  in  an  in-house  array  and  are  mapped  as  5's  in  IMGO  if  the  paths  are  found  to 
meet  the  various  criteria  defined  by  the  control  parameters  to  be  discussed.  The  working 
array  in  this  form  is  what  makes  up  the  output  file  of  the  algorithm.  When  an  image  is 
created  using  this  information,  the  code  5  pixel  locations  can  be  viewed  separately, 
marking  the  locations  of  algorithm-accepted  shiptracks. 

Roadway  begins  with  a  call  to  Indexgen  (described  below).  It  then  begins  scanning 
the  block  image  line  by  line  for  neighborhood  representatives  (code  3  pixels).  Once  a 
representative  is  found,  another  search,  centered  on  the  representative,  is  conducted  to 
look  for  other  nearby  representatives  that  may  lie  along  a  mutual  shiptrack  path  segment. 
The  search  is  conducted  in  the  horizontal  direction  for  plus  or  minus  Radius  pixel  length 
units,  and  along  the  vertical  (down  direction  only)  Radius  pixel  length  units  for  other 
code  3's.  Once  a  potential  shiptrack  path  is  found,  the  coordinates  of  the  representatives 
are  passed  on  to  Survey  and  Pave  for  analysis. 
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a.  Indexgen 

The  bulk  of  the  testing  of  potential  shiptrack  paths  involves  comparing  the  channel 
1,  3  and  4  pixel  values  along  the  line  between  two  neighborhoods  to  those  of  the  adjacent 
cloud.  This  is  done  by  marching  along  the  pixel  path  between  two  neighborhoods,  pixel 
by  pixel,  and  comparing  the  local  characteristics  of  the  path  to  the  cloud  characteristics 
found  on  either  side  of,  and  directly  perpendicular  to,  the  path  itself. 

For  each  possible  path  orientation,  the  subsequent  "testing"  subroutines  need  to 
know  the  locations  (or  addresses)  of  the  cloud  pixels,  out  to  a  distance  of  1 8  units  in 
either  direction,  along  the  path  perpendicular  centered  on  each  path  point.  To  save  each  of 
the  subsequent  subroutines  from  having  to  compute  these  addresses  each  time,  this  is 
done  only  once  in  Indexgen. 

Eight  possible  path  perpendicular  directions  are  considered  for  simplicity.  For 
each  of  the  eight  directions,  an  array  of  relative  adjacent  cloud  pixel  addresses  is 
computed  and  stored  for  ready  access.  This  information  is  made  available  in  the 
subsequent  testing  subroutines 

b.  Survey 

Survey  finds  the  addresses  (image  line  and  element)  of  each  pair  of  neighborhood 
representatives  that  are  sufficiently  close  to  each  other  (described  by  control  parameter 
Radius)  to  form  a  shiptrack  path  segment.  The  subroutine  connects  the  representatives 
with  a  string  of  4's,  mapping  each  path  out  in  a  temporary  memory  space  to  be  checked 
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by  Pave.  The  orientation  of  each  path  are  then  computed  and  assigned  one  of  eight 
possible  orientation  codes.  These  orientation  codes  are  used  to  find  the  appropriate 
address  array  (computed  by  Indexgen)  for  the  path  perpendicular  points  used  in  the  Pave 
checks. 

c.  Pave 

Up  to  this  point  the  algorithm  has  found  sufficiently  bright  "neighborhoods"  of 
pixels  and,  provided  they  were  within  a  certain  maximum  distance  apart,  marked  the 
paths  between  them  as  potential  shiptrack  segments  (code  4's).  Pave  (with  its  subsequent 
calls  to  Gravel  and  Landscape)  is  where  the  actual  testing  of  the  potential  paths  occurs  to 
determine  if  they  exhibit  properties  (as  defined  by  the  control  parameters)  characteristic  to 
shiptracks.  These  properties  include  brightness  (channels  land  3)  and  temperature 
differences  with  the  adjacent  cloud  field  and  absolute  brightness  gradients  in  channels  1, 
3  and  4. 

Pave  takes  the  addresses  of  neighborhood  representatives  that  mark  the  ends  of  a 
possible  shiptrack  segment  and  the  temporary  roadway  map  generated  by  Survey.  The 
subroutine  then  examines  the  path  segment,  one  pixel  at  a  time  comparing  the  local  cloud 
features  along  the  path  with  those  of  the  adjacent  cloud  found  on  both  sides  of  the  path. 
This  is  done  by  first  loading  the  channel  3  brightness  information  of  the  adjacent  cloud 
into  a  separate  2-dimensional  array  that  is  orientated  in  the  same  direction  as  the  path 
itself  (the  orientation  direction  and  the  associated  pixel  addresses  calculated  by 
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Indexgen).  The  subroutine  then  examines  each  1 -dimensional  path  perpendicular  array 
for  each  of  the  pixels  along  the  path  and  performs  brightness  comparison  tests  between 
the  different  fixed  subdivisions  (Fig.  5)  of  the  path  perpendicular. 

The  average  channel  3  brightness  values  are  computed  for  each  of  the  regions.  For 
all  but  the  Subfield  region,  these  averages  are  computed  by  simply  adding  the  pixel 
brightness  values  and  dividing  by  the  number  of  pixel  units  across.  In  the  case  of  the 
Subfield  region,  a  special  bias  is  put  in  to  help  account  for  shiptracks  that  were 
significantly  narrower  than  the  subfield  region  itself.  This  bias  effectively  sets  the 
subfield  average  to  the  average  brightness  value  of  any  two  or  more  pixels  that  both  fall 
within  the  subfield  region  itself  and  are  greater  that  the  straight  numerical  brightness 
average  within  the  region;  essentially  an  average  of  the  above  average  pixels.  If  there  are 
not  two  or  more  pixels  that  meet  this  criterion,  the  subfield  average  is  set  to  the  simple 
numerical  average  brightness  within  the  subfield  region.  Thus,  when  there  is  a 
significantly  bright  and  narrow  shiptrack,  the  subfield  value  used  in  the  shiptrack 
path/adjacent  cloud  comparison  tests  is  significantly  brighter  than  the  numerical  average 
of  the  subfield  pixels  and  is  a  better  representative  of  the  actual  shiptrack  than  a  simple 
numerical  average  of  the  subfield  pixels. 

Pave  performs  three  simple  channel  3  brightness  comparison  tests  for  each  pixel 
along  the  path  segment:  1)  The  subfield  average  must  be  brighter  than  the  lullfield 
average  by  Thresh3(l)  units,  2)  The  subfield  average  must  be  brighter  than  the  nearfield 
average  by  Thresh3(2)  units  and,  3)  The  farfield  average  minus  the  nearfield 
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Figure  5.  Pave  path  perpendicular  subregions 
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average  must  be  less  than  Thresh3(3)  units.  If  Pathresh  percent  of  the  pixels  along  the 
path  segment  pass  all  three  of  the  above  tests,  the  path  is  sent  on  to  Gravel  and  then  to 
Landscape  for  further  testing. 

1.  Gravel 

Gravel  is  designed  to  filter  out  natural  quasi-linear  IMG3  features  that  are  actually 
gaps  in  the  clouds,  edges  of  continents  or  dense  middle  or  high  cloud  shields.  It  uses 
channel  1  and  4  data  to  reject  potential  shiptrack  features  that  exhibit  sharp  visible 
brightness  gradients  (cloud  gaps),  and/or  sharp  temperature  gradients  (continents  or  high 
cloud  shield  edges). 

The  subroutine  looks  at  a  3  pixel  wide  region  around  each  path  segment  point  and 
a  4  pixel  wide  region  symmetrically  spaced  on  both  sides  of  path  along  the  path 
perpendicular.  Within  these  regions,  the  channel  1  and  4  brightness  values  are  averaged 
and  used  to  compute  several  variables  that  are  subsequently  used  in  tests  designed  to 
accept  or  reject  the  path  segment  based  on  visible  contrasts  with  the  surrounding  cloud 
and  temperature  and  visible  gradients.  Figure  6  depicts  the  regions  along  each  path 
perpendicular  and  Table  2  lists  the  variables  computed  from  the  channel  1  and  4 
brightness  values  within  those  regions. 
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Figure  6.  Gravel  path  perpendicular  regions 


TABLE  3 
GRAVEL  COMPUTATIONS 

Variables  computed  for  each  path  perpendicular 

Subl  =  Average  channel  1  brightness  within  the  Sub  region 

Sub4  =  Average  channel  4  brightness  within  the  sub  region 

Farla  (Far lb)  =  Average  channel  1  brightness  within  Far-A  (Far-B)  region 

Far4a  (Far4b)  =  Average  channel  4  brightness  within  Far-A  (Far-B)  region 

Far  lave  =  (Farla  +  Farlb)  /  2 

Far4ave  =  (Far4a  +  Far4b)  /  2 

Gradl  =  Farlb  -  Farla 

Grad4  =  Far4b  -  Far3a 

Variables  computed  for  the  entire  path  segment 

Gradl  ave  =  Average  channel  lpath  perpendicular  gradient  along  the  path 
Grad4ave  =  Average  channel  4  path  perpendicular  gradient  along  the  path 
Pathcount  =  The  number  of  pixels  along  the  path  segment 
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The  Gravel  logic  is  best  presented  by  way  of  a  flow  chart  (Fig.  7).  The 
sub-algorithm  is  entered  with  a  potential  shiptrack  path  segment  and  exited  with  an  accept 
or  reject  flag  that  is  sent  back  to  Pave.  Control  parameters  are  shown  in  italics  in  the 
flow  chart  Gravl  is  an  absolute  channel  1  brightness  threshold.  Grav2,  Grav3,  Grav4, 
BogusS  and  Bogus6  are  channel  1  and  4  gradient  thresholds.  Finally,  Bogusl  and  Bogus! 
are  minimum  accepted  path  perpendicular  percentage  values. 

2.  Landscape 

Landscape  is  designed  to  analyze  potential  shiptrack  path  segments  based  on 
channel  3  brightness  gradients  characteristics.  The  idea  is  to  force  potential  shiptrack 
path  segments  to  be  features  confined  by  local  channel  3  brightness  gradient  maxima  and 
minima   Like  Gravel ,  Landscape  analyzes  and  tests  single  path  segments  passed  on  to 
it  from  Pave.  The  subroutine  performs  certain  gradient  tests  on  each  path  perpendicular 
and  requires  a  minimum  percentage  of  the  path  perpendiculars  to  pass  before  the  decision 
is  made  to  accept  or  reject  the  path  segment. 

The  first  thing  that  the  subroutine  does  is  reject  path  segments  that  are  less  than 
20  pixels  long.  This  filter  is  essentially  an  arbitrary  CPU  time  saving  step  that  was  placed 
here  in  the  last  (and  most  recently  added)  subroutine  to  speed  up  the  analysis.  This 
restriction  could  have  easily  been  placed  in  Roadway  where  a  maximum  path  segment 
length  limit  of  Radius  pixels  was  imposed 
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The  subroutine  next  sets  out  to  compute  the  instantaneous  channel  3  brightness 
gradient  along  each  path  perpendicular  to  define  the  path  edges.  The  first  step  in  this 
process  is  smoothing  the  brightness  values  along  the  path  perpendicular.  A  three  point 
running  mean  of  the  brightness  values  is  computed  from  plus  or  minus  16  pixels  from  the 
path  center.  These  smoothed  brightness  values  are  then  used  to  compute  a  three  point 
running  gradient  along  the  path  perpendicular. 

Once  the  instantaneous  gradient  is  computed,  the  subroutine  finds  the  local  (plus 
or  minus  9  pixels  from  the  path  center)  gradient  maximum  and  minimum.  A  restriction  is 
then  imposed  on  the  path  segments,  requiring  them  to  have  one  positive  and  one  negative 
gradient  extreme  and  that  these  gradient  extremes  have  an  absolute  value  which  is  greater 
than  the  control  parameter  Pathgrad  but  less  than  an  arbitrary  cutoff  of  40. 

The  next  restriction  the  subroutine  places  on  the  path  perpendicular  is  to  require 
the  shiptrack  path  width  to  be  greater  than  3  pixels.  This  restriction  is  imposed  to 
eliminate  accepted  path  segments  that  are  actually  small  scale  gaps  on  either  side  of  thin 
quasi-linear  clouds.  The  path  width  is  defined  as  the  length  between  the  gradient 
extremes  plus  2  (Fig.  8). 
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Figure  8.  Landscape  pathedges,  arbitrarily  set  1  pixel  outward  from  the 
minimum  and  maximum  gradients. 


Next,  the  subroutine  sets  out  to  reject  features  having  excessively  noisy 
brightness  gradients.  This  is  done  comparing  the  brightness  gradients  out  to  plus  or 
minus  1 5  pixels  from  the  center  to  the  local  (plus  or  minus  9)  gradient  extremes  and 
rejecting  those  path  perpendiculars  which  have  more  than  one  gradient  greater  than  or 
equal  to  the  local  gradient  extremes. 

When  the  subroutine  is  through  analyzing  each  path  perpendicular,  the  percentage 
of  those  that  passed  the  above  test  is  computed.  If  this  percentage  is  found  to  be  greater 
than  the  control  parameter  Thresh3wd,  the  path  is  accepted,  if  not,  it  is  rejected. 
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6.  OutimgO 

This  subroutine  is  the  final  subroutine  in  the  main  do-loop.  The  working  array  is 
passed  from  the  main  program  to  OutimgO  where  it  is  written  into  the  giant  image  output 
file  in  the  corresponding  positions  to  the  original  input  files. 

B.  OUTPUT 

The  algorithm  generates  a  giant  integer  output  file  containing  a  series  of  2's,  3*s  and 
5's.  The  2's  correspond  to  bright  pixels  on  the  original  channel  3  image  that  stand  out 
from  their  local  surroundings.  The  3's  map  local  neighborhood  representatives  which 
mark  the  ends  of  potential  shiptrack  path  segments  and  the  5's  mark  the  connecting  points 
between  these  end  points.  By  using  a  condensing  program  (fixcondO)  and  a  utility  called 
colors  (which  can  represent  each  of  the  three  integers  as  a  separate  color),  this  output  file 
can  be  easily  viewed  on  the  monitor  or  made  into  hard  copies. 

There  are  two  ways  to  view  the  algorithm  output  with  the  original  image  to  determine 
how  well  the  particular  run  performed.  The  quickest  and  easiest  way  is  to  use  a  utility 
called  flicker  to  rapidly  alternate  between  the  original  and  the  output  images  on  the 
monitor.  The  second  option  is  to  make  hard  copies  of  the  original  images  and 
transparencies  of  the  output  image  (both  on  the  IDEA  lab's  RGBII  laser  printer)  and 
overlay  the  transparency  on  the  original  image  hard  copy. 
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IV.  PROCEDURES 

As  described  in  chapter  three,  the  current  shiptrack  detection  algorithm  has  20 
variable  control  parameters.  Before  a  meaningful  study  could  be  conducted  on  the 
effectiveness  of  the  algorithm  at  detecting  shiptracks,  a  preliminary  determination  of  the 
optimum  settings  had  to  be  made.  Once  these  settings  were  established,  additional 
satellite  passes  were  chosen  and  the  algorithm  run  on  each  pass  using  the  optimum 
settings.  The  runs  were  then  separately  analyzed  and  the  effectiveness  of  the  algorithm 
was  subjectively  determined  for  each. 

The  project  was  broken  down  into  two  phases.  The  first  phase  involved  choosing  a 
single  satellite  pass  that  contained  multiple  shiptracks  of  varying  lengths,  widths  and 
brightness  to  be  used  as  a  baseline  with  which  to  test  and  optimize  the  algorithm  settings. 
The  shiptrack  locations  were  manually  (subjectively)  determined  on  the  image  and 
multiple  runs  of  the  algorithm  were  made  and  compared  to  the  subjective  analysis.  The 
optimum  settings  for  the  algorithm  were  determined  based  on  the  number  of  detections 
and  false  detections  of  each  run. 

The  second  phase  of  this  study  involved  choosing  additional  satellite  passes, 
subjectively  determining  the  shiptrack  locations  and  analyzing  the  results  from  each  run 
of  the  algorithm  (using  the  settings  found  in  phase  1).  The  effectiveness  of  the  algorithm 
was  determined  by  comparing  the  subjective  analysis  to  the  objective  analysis  of  the 
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algorithm  by  means  of  a  series  of  statistical  parameters  developed  specifically  for  this 
study. 

A.  PHASE  1 

A  satellite  pass  from  NOAA-9  made  on  July  13,  1987  off  of  the  West  Coast  of  North 
America  (Figs.  1 ,  2  and  3)  was  chosen  as  the  initial  test  image  because  it  was  found  to 
contain  a  large  number  of  shiptracks  of  varying  lengths,  widths  and  brightness  and 
covered  a  significantly  large  ocean  area.  Hard  copies  of  these  files  were  made  using  a 
Tektronix  RGBII  laser  printer  in  the  IDEA  lab  on  which  the  shiptracks  were  located, 
numbered  and  highlighted  manually. 

Locating,  highlighting  and  numbering  the  shiptracks  on  the  hard  copies  was 
necessary  in  order  to  subjectively  create  a  standardized  image  to  be  compared  to  each  run 
of  the  algorithm.  The  procedure  involved  painting  (an  Avian  utility  where  512x512 
portions  of  an  overview  are  blown  up  in  full  resolution  and  viewed)  the  overview  and 
hand  drawing  the  shiptracks  seen  on  the  screen  onto  the  hard  copies.  Locating  the 
shiptracks  on  the  monitor  and  then  highlighting  and  numbering  them  on  the  hard  copies 
was  necessary  due  to  the  poor  resolution  of  the  hard  copies  themselves. 

Each  time  the  algorithm  was  run,  a  giant  byte  file  was  created.  These  files  were 
converted  to  integer  files  and  condensed,  much  like  the  giant  image  files  were,  using  a 
program  called  fixcondO.  By  making  transparencies  of  these  output  files  and  overlaying 
them  on  the  image  hard  copies,  the  detections  and  false  detections  of  each  run  were  easily 
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and  unambiguously  noted.  The  optimum  settings  were  selected  based  on  the  number  of 
shiptracks  detected  and  the  number  of  false  detections  made. 

With  20  control  parameters  available,  in  theory,  a  large  number  of  possible  setting 
combinations  is  possible.  Fortunately,  prior  work  on  a  previous  512x512  version  of  the 
algorithm  established  a  few  of  the  settings  used  in  Census  and  Neighborhood,  leaving  17 
relatively  untested  parameters.  An  additional  3  parameters  from  Gravel  were  assumed  to 
have  only  minimal  effects  on  the  algorithm  efficiency  and  were  left  out  of  the  testing. 
This  left  14  untested  control  parameters  that  were  assumed  to  play  a  major  role  in  the 
algorithm  efficiency  (see  Table  4). 

B.  PHASE  2 

Once  the  optimum  settings  of  the  algorithm  were  determined,  the  attention  was 
shifted  towards  testing  the  algorithm  efficiency  on  suitable  alternate  satellite  passes.  The 
first  image  to  be  analyzed  with  the  optimum  settings  after  the  original  test  image  was  a 
Low3  (vice  channel  3)  version  of  the  original  test  image.  Preparing  this  pass  for  the 
algorithm  involved  re-nmning  the  Datadump  and  reaHbye  programs  to  create  a  Low3, 
giant  output  file  to  be  used  instead  of  the  channel  3  file.  After  the  algorithm  was  run  and 
the 
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TABLE  4 
TESTED  CONTROL  PARAMETERS 


Setting 

Description 

i 
Subroutine 

Thigh 

Maximum  channel  4  temperature  reading  of 
the  potential  shiptrack  segment. 

Census 

Tlow 

Minimum  channel  4  temperature  reading  of 
the  potential  shiptrack  segment. 

Census 

Radius 

Maximum  search  radius  to  find  connecting 
neighborhood  representative. 

Roadway 

Thresh3(l) 

Channel  3  path/full  field  minimum  brightness 
contrast. 

Pave 

Thresh3(2) 

Channel  3  sub/far  field  minimum  brightness 
contrast. 

Pave 

Thresh3(3) 

Channel  3  near/far  field  maximum  brightness 
contrast. 

Pave 

Pathresh 

Minimum  percentage  of  path  perpendiculars 
that  must  pass  the  Thresh3  tests. 

Pave 

Pathgrad 

Minimum  channel  3  brightness  gradient 
across  the  path  segment. 

Landscape 

Thresh3wd 

Minimum  percentage  of  path  perpendiculars 
that  must  pass  the  Pathgrad  test. 

Landscape 

Gravl 

Minimum  channel  1  brightness  value  of  the 
potential  shiptrack  segment. 

Gravel 

Bogus  1 

Minimum  percentage  of  path  perpendiculars 
that  pass  pathkept  1  tests. 

Gravel 

Bogus2 

Minimum  percentage  of  path  perpendiculars 
that  pass  pathkept  4  tests. 

Gravel 

Bogus5 

Miniminn  path  channel  4  gradient  average 

Gravel 

Bogus6 

Minimum  path  channel  1  gradient  average 

Gravel 
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subsequent  analysis  completed  on  this  image,  three  additional  passes  were  chosen  and 
prepared  in  an  identical  manner  to  that  in  which  the  original  test  image  was  in  phase  1 . 
This  preparation  included  creating  the  giant  input  tiles  and  hand  drawing  the  shiptracks 
on  the  channel  3  image  hard  copies.  Once  the  subjective  analysis  was  complete  on  each 
pass,  the  detection  algorithm  was  run  and  the  output  files  analyzed. 

Although  the  algorithm  was  not  specifically  designed  to  pick  up  any  specific  region 
of  a  generic  shiptrack,  during  the  analysis  a  distinction  was  made  between  the  head  region 
of  a  shiptrack  the  rest  of  the  track  segment.  Shiptracks  whose  heads  were  visible  on  the 
image  were  categorized  separately  from  those  that  did  not,  and  shiptrack  detections  that 
included  the  head  region  of  a  shiptrack  (to  within  a  20  km  error  margin)  were  noted.  This 
emphasis  on  the  shiptrack  heads  was  done  based  on  the  assumption  that  the  head  of  a 
shiptrack  is  the  most  recently  formed  part  of  the  track  and  is  therefore  much  less 
susceptible  to  dispersion  and  wind  shears  that  influence  the  track  down  wind  of  the 
formation  region.  Additionally,  the  head,  or  formation  region,  of  a  shiptrack  is  the  most 
critical  part  of  the  track  for  the  purposes  of  both  formation  mechanism  studies  and  ship  to 
shiptrack  correlation  studies. 

The  analysis  process  involved  collecting  data  from  both  the  channel  3  and  the 
algorithm  output  images  and  performing  a  series  of  simple  statistical  calculations  intended 
to  present  the  effectiveness  of  the  algorithm  on  each  run.  The  types  of  data  collected  on 
each  run  are  listed  in  Table  5.  The  performance  statistics  developed  to  present  the 
algorithm  efficiency  outlined  in  Table  6. 
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TABLE  5 

DATA  COLLECTED  FOR  EACH 
SATELLITE  PASS 

NS  =  0  Number  of  ST  subjectively  observed 

NH  =  *NumberofHT  subjectively  observed 

SL  =  °Total  length  of  observed  ST 

HL  =  oTotal  length  of  observed  HT 

OA  =  Total  open  ocean  area  in  Km2  x  106 


DATA  COLLECTED  FOR  EACH 
ALGORITHM  RUN 

STD  =  Number  of  ST  objectively  detected 

HTD  =  Number  ofHT  objectively  detected 

NHD  =  •Number  of  ST  heads  detected 

STL  =  Total  detected  ST  length 

SHL  =  Total  detected  HT  length 

NFD  =  Number  of  false  detections 


OST  =  shiptracks 

*HT  =  shiptracks  with  clearly  visible  heads 

oBased  on  1  pixel  =1.1  km 

•Shiptrack  detection  within  20km  of  head  location 
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TABLE  6 
ALGORITHM  PERFORMANCE  STATISTICS 


*ST  detection  rate  (SR)  =  STD  /  NS 

0  STH  detection  rate  (HR)  =  HID  /  NH 

ST  length  percentage  (SL)  =  STL  /  SL 

STH  length  percentage  (HL)  =  SHL  /  HL 

ST  dectection  confidence  (SC)  =  STD  /  (STD  +  NFD) 

False  detection  rate  (FR)  =  NFD  /  (STD  +  NFD) 

Head  detection  rate  (HD)  =  NHD  /  STH 

False  detections  per  area  (FD)  =  NFD  /  OA 


*  Denotes  shiptrack 

0  Denotes  shiptracks  with  clearly  visible  heads 
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V.  RESULTS 

A.  PHASE  1 

The  objective  of  phase  1  of  the  project  was  to  determine  the  optimum  algorithm 

control  parameter  settings.  The  first  step  in  determining  how  well  any  particular  setting 
combination  effects  the  algorithm's  performance  was  creating  a  subjective  shiptrack 
analysis  from  which  to  score  each  individual  run.  Such  a  standardized  subjective 
shiptrack  analysis  was  performed  on  the  initial  test  image  in  accordance  with  the  steps 
outlined  in  chapter  4.  Channel  3  images  of  the  northern  and  southern  half  of  the  original 
test  image  is  presented  in  Figs.  9  and  10.  Recall  the  northern  half  of  this  pass  was  used 
earlier  to  illustrate  the  appearance  of  shiptracks  in  the  visible,  near-IR  and  thermal-IR 
channels  (Figs.  1,  2  and  3).    The  subjective  shiptrack  analysis  for  this  pass  is  presented 
by  Figs.  1 1  and  12.  This  analysis  was  then  used  as  "ground  truth"  in  scoring  individual 
algorithm  runs  as  described  in  chapter  IV. 

The  next  step  in  the  project  involved  logically  choosing  appropriate  control 
parameter  setting  combinations,  running  the  algorithm  and  analyzing  the  results.  By  the 
time  this  study  had  begun,  a  51 2  x  5 1 2  version  of  the  basic  algorithm  had  been  in 
existence  for  almost  a  year  and  the  optimum  control  parameter  settings  already  generally 
determined.  These  initial  settings  provided  a  good  starting  point  for  the  first  phase  of  the 
project. 
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The  initial  objective  of  the  first  run  of  the  algorithm  on  the  test  image  was  to 
determine  how  well  the  algorithm  performed  with  the  standardized  control  parameter 
settings.  From  the  second  run  on,  setting  combinations  were  altered  and/or  internal 
modifications  made  to  the  code  in  an  attempt  to  either  improve  specific  performance 
characteristics  or  determine  the  effect  an  alteration  of  one  or  more  of  the  control 
parameters  had  on  the  output.  A  separate  512x512  version  of  the  algorithm  was  updated 
and  was  used  to  pre-check  many  of  the  changes  on  small  regions  of  the  full  pass. 

Table  7  outlines  the  specific  performance  results  and  control  parameter  settings  of 
each  run  conducted  in  this  phase  of  the  research.  Columns  of  Table  7  describe  valid 
shiptrack  detections  (Det),  false  detections  (F/D)  and  all  of  the  tested  control  parameters 
discussed  in  chapters  m  and  IV.  Also  shown  are  specific  internal  changes  that  were 
made  to  the  algorithm  between  runs.  In  all,  1 8  runs  of  the  algorithm  were  made,  the  last 
two  of  which  were  determined  to  present  the  optimum  control  parameter  settings/internal 
code  modifications  for  the  algorithm. 

The  first  of  the  internal  modifications  made,  listed  as  "Landscape  logic  error"  in 
Table  7,  refers  to  a  logic  error  that  was  found  within  the  code  that  defaulted  the  main 
do-loop  in  the  Landscape  subroutine.  The  error  caused  Landscape  to  be  more  restrictive 
in  its  path  acceptance  tests  than  intended.  On  a  run  of  the  512x512  version  of  the 
algorithm  immediately  following  the  logic  error  correction,  the  algorithm  was  found  to  be 
much  less  discriminating  in  its  path  segment  testing,  finding  an  increased  number  of  valid 
shiptracks  as  well  as  false  detections.  This  finding  was  confirmed  on  the  full  pass  run 
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(number  five)  which  found  28  valid  shiptracks  and  produced  23  false  detections.  The 
increased  number  of  false  detections  prompted  a  second  series  of  internal  modifications  to 
the  code  intended  to  increase  the  algorithm's  filter  efficiency  without  sacrificing  the  valid 
detection  rate. 

The  second  internal  change,  listed  as  "Gravel  modification"  in  Table  7,  was  an 
attempt  to  eliminate  a  specific  recurring  false  detection  off  the  coast  of  Southern 
California.  The  feature  causing  the  false  detection  was  an  anomalously  bright  ridge  in  an 
otherwise  broadly  sloping  brightness  field  of  medium  high  cloud.  The  modification 
changed  one  of  the  path  perpendicular  requirements  within  Gravel's  Pathkeptl  tests  (Fig. 
7).  Originally,  each  path  perpendicular  was  required  to  have  a  Subl  field  brighter  than 
Far  lave  (Fig.  6  and  Table  3).  The  change  required  that  each  path  perpendicular  have  a 
Subl  field  brighter  than  both  the  Far- A  and  Far-B.  This  change  was  found  to  help 
eliminate  certain  false  detections  but  overall  produced  an  unacceptable  decline  in  the  valid 
shiptrack  detection  rate  and  was  subsequently  reversed. 

The  third  change,  listed  as  "Landscape  modification"  in  Table  7,  was  made  at  the 
same  time  as  the  Gravel  Modification  (above)  and  refers  to  a  lowering  of  the  minimum 
pathwidth  accepted  in  the  Landscape  subroutine  from  5  to  3  pixels.  This  change  was 
made  in  an  attempt  to  allow  the  algorithm  to  pick  up  more  shiptrack  heads.  The  change 
was  determined  successful  and  was  kept  for  all  subsequent  runs. 
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TABLE  7 

PERFORMANCE  SUMMARY  AND 

CONTROL  PARAMETER  SETTINGS 

JULY  13,  1987  TEST  IMAGE 


RunDetF/DA      B       CDEF       G      H      I  J  KLMN 

1  22  8   278  291   50  1  8   88   80   8   80 

2  30  16  278  291  50  2  8   88   80   8   80  70  60  60  50  10 

3  27  8   273  299  50  2  8   88   80   8   80  70  60  60  50  10 

4  27  10  273  299  45  1  5   90  75   5   70  70  60  60  50  10 

Landscape  logic  error  corrected 

5  28    23    273    299     45    1    5      90     75      5        70  70  60    60  50    10 

Gravel/Landscape  modifications  made 


6 

23 

5 

273 

299 

45  1 

5 

90 

75   5 

70 

70 

60 

60 

50 

10 

7 

24 

6 

273 

299 

50  1 

6 

90 

75  - 

- 

70 

60 

60 

50 

10 

8 

24 

11 

273 

299 

50  1 

5 

100 

70  - 

- 

70 

60 

60 

50 

10 

Gravel  modification  reversed 

9 

29 

20 

273 

299 

50  1 

6 

90 

75   - 

- 

70 

62 

60 

50 

10 

10 

27 

19 

273 

299 

50  1 

6 

90 

75   5 

75 

75 

62 

60 

50 

10 

11 

23 

7 

273 

299 

50  1 

8 

90 

90  - 

- 

70 

62 

62 

60 

10 

New  Landscape 

test  added 

12 

25 

9 

273 

299 

50  2 

7 

250 

70   5 

70 

70 

63 

60 

50 

10 

13 

25 

10 

273 

299 

50  1 

8 

150 

70   5 

70 

70 

63 

60 

50 

10 

14 

20 

8 

273 

299 

50  2 

8 

88 

65   5 

70 

90 

63 

60 

30 

10 

15 

25 

9 

273 

299 

50  2 

8 

150 

70   5 

70 

70 

63 

60 

50 

10 

16 

25 

11 

273 

299 

50  2 

8 

150 

70   5 

60 

70 

63 

60 

50 

10 

17 

28 

11 

273 

299 

50  2 

10 

250 

65   10 

70 

50 

63 

60 

70 

7 

18 

25 

5 

273 

299 

55  2 

8 

88 

80   8 

80 

70 

60 

60 

50 

10 

A  = 

B  = 

Thigh 
Tlow 

H  =  Pathgrad 
I  =  Thresh3wd 

C  = 

Radius 

J  =  Gravl 

D  = 
E  = 
F  = 
G  = 

Thresh3(l) 
Thresh3(2) 
Thresh3(3) 
Pathresh 

K  =  Bogusl 
L  =  Bogusl 

M  =  Bogus  5 
N  =  Bogus6 

*Blanks  in  columns  H  and  I  denote  Landscape  subroutine  turned  off 
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The  last  modification  listed  as  "New  Landscape"  in  Table  7,  refers  to  a  test  added  to 
the  Landscape  subroutine  that  rejects  potential  shiptrack  path  segments  that  have 
excessively  noisy  brightness  gradients.  This  test  was  determined  to  be  successful  in 
increasing  the  Landscape  filter  efficiency  and  was  kept  for  all  following  runs.  The  logic 
specifics  of  this  test  are  described  fully  in  the  Landscape  section  of  chapter  EH. 

The  final  two  runs  conducted  in  phase  1  were  selected  as  representing  optimum 
control  parameter  settings  based  on  the  algorithm's  performance  on  the  single  test  image. 
Run  17  settings  (hereafter  referred  to  as  Run  A  settings)  produced  a  high  number  of 
detections  with  a  moderate  number  of  false  detections  (Figs.  13  and  14).  This  setting 
combination  can  be  considered  optimum  when  the  number  of  false  detections  made  by  the 
algorithm  is  not  as  critical  an  issue  as  the  number  of  detections.  Run  1 8  (hereafter 
referred  to  as  Run  B)  settings  on  the  other  hand  produced  a  moderate  number  of  false 
detections.  The  Run  B  setting  combination  was  found  to  be  the  most  conservative  and 
could  be  used  when  the  number  of  false  detections  is  as  least  as  critical  as  the  number  of 
detections  made  (Figs.  15  and  16). 

The  sub-algorithms  which  call  the  various  control  parameters  that  were  tested  in 
phase  2  can  be  thought  of  falling  into  two  general  categories:  Those  that  search  for 
potential  shiptrack  path  segments  and  those  that  perform  acceptance  tests  on  the  path 
segments  found.  Run  A  settings  are  designed  to  be  somewhat  relaxed  in  their  shiptrack 
path  segment  search  thresholds  (Table  7  columns  D  through  G)  but  relatively  strict  in 
their  acceptance  tests  thresholds  (Table  7  columns  H  through  N).   Recall  from  chapter  HI 
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that  parameters  D,  E,  and  F  are  channel  3  brightness  thresholds  used  in  Pave  to  ensure 
potential  shiptrack  path  segments  are  sufficiently  brighter  than  the  adjacent  cloud  field. 
Parameter  G  is  the  minimum  percentage  of  the  potential  path  segment  that  must  meet 
these  brightness  criteria.  Parameters  H  and  I  are  used  in  Landscape  as  filter  parameters. 
H  is  the  minimum  shiptrack  pathedge  gradient  allowed  by  Landscape  and  I  is  the 
percentage  of  path  perpendiculars  that  must  meet  the  minimum  gradient  standards.  The 
remaining  parameters  are  used  in  Gravel  (Fig  7).  Parameter  J  is  the  minimiun  channel  1 
brightness  threshold  of  the  shiptrack  path  segment  Parameters  K  and  L  represent  the 
minimum  percentage  of  the  shiptrack  path  perpendicular  that  must  meet  the  various 
channel  1  and  3  brightness  and  gradient  tests.  Finally,  parameters  M  and  N  are  the 
minimum  average  channel  1  and  4  path  segment  gradients. 

In  contrast  to  Run  A,  Run  B  settings  are  more  strict  in  their  search  thresholds  (D 
through  G)  but  less  restrictive  in  their  acceptance  test  thresholds  (H  through  N)  than  Run 

A.  This  difference  in  approach  to  finding  valid  shiptracks  is  the  cause  for  the 
dissimilarities  between  the  output  runs  using  Run  A  and  Run  B  settings. 

B.  PHASE  2 

The  additional  satellite  passes  chosen  for  the  second  phase  of  the  project  came  from 
the  FIRE  tape  library  in  the  IDEA  lab.  The  images  were  taken  by  NOAA-9  and  10  in 
the  summer  of  1987  and  are  all  centered  off  of  the  West  Coast  of  North  America. 
Specific  dates  are  as  follows:  June  27,  July  7,  July  8. 


44 


1.  Case  study  1 

The  same  July  13,  1987  pass  that  was  used  as  the  original  test  image  in  phase  1  was 
also  used  as  the  first  case  study  in  phase  2.  Figures  9  and  10  are  condensed  (every  fourth 
pixel)  channel  3  images  of  the  northern  and  southern  halves  of  the  full  satellite  pass. 
Although  of  reduced  resolution,  a  majority  of  the  shiptracks  subjectively  observed  can  be 
seen.  Figures  1 1  and  12  show  the  subjective  shiptrack  analysis  made  on  this  pass,  1 1 
being  the  northern  and  12  the  southern  half.  Tables  8  and  9  summarize  the  subjective  and 
algorithm  run  findings  for  the  channel  3  and  low3  versions  of  the  July  13  case  study. 
Forty  shiptracks  were  observed  (NS)  in  the  subjective  analysis  of  this  image,  23  of  those 
falling  into  the  category  of  having  clearly  defined  heads  (Nil).    Figures  13  and  14  show 
the  algorithm  (Run  A  settings)  output  for  the  northern  and  southern  halves  respectively. 
Overall  Run  A  produced  39  detections,  28  of  which  corresponding  to  valid  shiptracks 
(STD),  and  detected  roughly  38%  of  the  total  shiptrack  length  (STL/ST).  The  Run  B 
settings  (Figs.  15  and  16)  were  slightly  more  conservative,  producing  30  detections  (25  of 
which  corresponding  to  valid  shiptracks)  and  detected  roughly  31%  of  the  total  shiptrack 
length.  Runs  A  and  B  on  the  low3  version  of  the  pass  (Table  9)  did  not  score  as  well  as 
their  channel  3  counterparts,  in  each  case  producing  a  smaller  number  of  detections  while 
maintaining  similar  valid  to  false  detection  ratios.  Detected  tracks  from  the  low3  version 
are  illustrated  on  Figs.  17  through  20. 
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2.  Case  Study  2 

The  June  27  pass  shows  an  extraordinary  number  of  shiptracks  concentrated  in  a 
relatively  small  area  off  of  the  coast  of  North  America.  A  total  of  52  shiptracks  are 
observed,  44  of  which  had  clearly  visible  heads.  Figure  21  shows  the  condensed  channel 
3  image  of  the  northern  half  of  the  pass  (no  shiptracks  were  observed  in  the  southern  half 
of  the  image)  while  Fig.  22  presents  the  subjective  analysis  made  on  that  portion  of  the 
image..  Figures  23  and  24  are  the  algorithm  output  files  from  Runs  A  and  B.  Table  10 
summarizes  the  findings  from  both  the  subjective  analysis  and  the  algorithm  runs  from 
this  case  study.  Contrary  to  the  findings  in  the  first  case  study,  both  runs  found  the  same 
number  of  valid  shiptracks  (STD=27),  although  not  necessarily  the  same  shiptracks,  with 
Run  A  actually  finding  a  fewer  number  of  false  detections  (NFD=6)  than  Run  B 
(NFD=7).  Similar  to  the  first  case  study  however,  Run  A  detected  a  higher  percentage  of 
total  shiptrack  length  (STL/ST)  than  Run  B  (19%  to  21%  respectively). 

3.  Case  study  3 

In  general,  shiptracks  did  not  appear  on  the  July  7  pass.  Although  19  shiptracks  are 
subjectively  observed,  very  few  had  the  brightness  and  clarity  observed  in  the  previous 
two  passes.  Additionally,  the  image  shows  a  large  number  of  north-south  running  cloud 
edges  in  the  low  sun  angle,  southeast  most  portion  of  the  image  and  consequently  was  an 
area  of  high  false  detections.  Figures  25  and  26  show  the  condensed  channel  3  images  of 
the  northern  and  southern  halves  of  the  pass  respectively  and  Figs.  27  and  28  show  the 
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subjective  shiptrack  analysis  made  on  each.  The  reader  should  be  reminded  that  the  hard 
copy  figures  do  not  display  all  the  detail  of  the  digital  data  and  the  overview  images  have 
reduced  resolution  (every  fourth  pixel)  compared  to  the  complete  subscene. 
Consequently  many  of  the  subtle  shiptracks  are  not  obvious  in  the  overview  figures.  Run 
A  (Figs.  29  and  30)  produced  a  higher  number  of  detections  and  found  a  greater 
percentage  of  total  shiptrack  length  than  Run  B  (Figs.  31  and  32).  Run  B,  however,  had 
a  higher  valid  to  false  detections  rate  than  did  Run  A.  The  specific  findings  of  each  run 
along  with  the  subjective  shiptrack  analysis  statistics  are  summarized  in  Table  1 1 . 

4.  Case  study  4 

Figs.  33  and  34  show  the  condensed  channel  3  images  from  the  July  8  pass, 
northern  and  southern  halves  respectively.  The  subjective  shiptrack  analysis  for  these 
images  are  shown  in  figs.  35  and  36.  Again,  this  image  showed  few  bright  and 
continuous  shiptracks  as  compared  with  case  studies  1  and  2.  A  total  of  16  shiptracks 
were  observed,  13  of  which  had  clearly  visible  heads.  Runs  A  (figs.  37  and  38)  and  B 
(figs.  39  and  40)  performed  slightly  better  than  the  July  7  and  are  summarized  along  with 
the  subjective  analysis  statistics  in  Table  1 2. 

5.  Summary 

The  data  outlined  in  the  Tables  9  through  1 2  was  used  to  compute  the  performance 
statistics  as  outlined  in  chapter  IV.  These  statistics  are  presented  in  Table  13.    Tlie  I  able 
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is  broken  down  into  Run  A  and  B  settings,  last  row  in  each  section,  labeled 
"combination",  was  computed  using  the  combined  number  of  shiptracks,  shiptrack  length 
etc.  from  each  run  within  that  section.  The  values  in  this  column  can  be  thought  of  as  the 
weighted  average  value  from  each  run. 

In  general,  algorithm  runs  using  Run  A  settings  detected  a  higher  percentage  of 
shiptracks  with  clearly  visible  heads  than  Run  B  (65%  and  58%  respectively)  and  a 
greater  percentage  of  these  shiptrack  lengths  (26%  and  23  %).  At  the  same  time 
however,  Run  A  settings  scored  lower  shiptrack  confidence  rates  than  Run  B  (63%  to 
72%),  producing  an  average  of  1 .3 1  false  detections  per  million  square  kilometers  as 
compared  to  an  average  of  only  0.87  false  detection  per  million  square  kilometers  for  Run 
B  settings. 

C.  FALSE  DETECTIONS 

Algorithm  false  detections  per  unit  ocean  area  were  pleasingly  low.  Many  of  the 
features  causing  false  detections  were  small  (usually  under  50  km  in  length)  but 
nonetheless  fulfilled  each  of  the  algorithm  objective  shiptrack  tests.  A  small  handful  of 
the  features  could  not  be  identified  and  fell  into  a  categorical  description  of  anomalous 
cloud  features.  The  majority  of  the  remaining  false  detections  fell  into  four  general 
categories;   1 )  Cloud  edges  in  low  sun  angle  regions,  2)  Thin,  elongated  stratoform 
clouds  over  water  (especially  near  the  edges  of  the  satellite  pass),  3)  Gravity  wave 
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interactions  with  the  marine  boundary  layer,  and  4)  Old  shiptrack  remnants.  Examples  of 
the  first  three  categories  arc  given  in  figs.  41  through  43. 

Figure  41  shows  a  full  resolution  (512x512  subscene)  channel  1  and  3  image  of  a 
north-south  running  cloud  edge  in  the  low  sun  angle  region  of  the  July  7  pass.  A  bright, 
linear  feature  is  clearly  seen  in  the  channel  3  image  along  the  eastern  edge  of  the  low 
cloud  centered  in  the  image.  This  feature  is  on  the  same  order  of  magnitude  as  a 
shiptrack  and  produced  a  false  detection  on  both  algorithm  runs.  Currently  no  adequate 
filter  has  been  designed  to  stop  the  algorithm  from  detecting  such  features. 

Figure  42  is  a  full  resolution  channel  1  and  3  image  taken  near  the  edge  of  the  July  8 
satellite  pass.  This  image  shows  apparently  thin  bright  clouds  in  both  channels  1  and  3 
surrounded  by  darker  adjacent  clouds.  Because  this  view  is  at  the  edge  of  the  satellite 
pass,  the  oblique  view  is  grossly  distorted  and  these  clouds  are  actually  much  wider  than 
they  appear.  This  feature  produced  a  false  detection  on  both  algorithm  runs  on  the  July  8 
pass.  A  potential  algorithm  modification  that  would  vary  the  maximum  pixel  width  of 
accepted  shiptracks  as  a  function  of  the  number  of  degrees  off  nadir  the  feature  is  located 
may  provide  a  means  of  eliminating  this  particular  problem. 

Finally,  Fig.  43  shows  both  a  channel  1  and  channel  3  full  resolution  image  of 
gravity  wave  phenomenon  off  of  the  Baja  Peninsula  on  the  July  13  pass.  Gravity  waves 
force  the  upper  saturated  marine  boundary  layer  to  come  in  contact  with  the  dryer  air 
above  in  a  sinusoidal  pattern.  As  the  saturated  air  comes  in  contact  with  the  dryer  air, 
the  cloud  droplets  become  smaller  due  to  evaporation  and  consequently,  the  visible  and 
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near-IR  reflectance  increases.  This  Is  seen  in  both  the  channel  1  and  channel  3  images. 
This  feature  produced  false  detections  on  both  algorithm  runs. 

Additional  study  of  the  reasons  for  false  detections  of  shiptracks  will  produce  better 
filters  for  the  algorithm,  allowing  less  restrictive  shiptrack  search  parameters.  This  will 
ultimately  lead  to  overall  improvements  in  the  algorithm's  performance. 
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Figure  9.   Northern  half  of  July  13,  1987  AVHRR  channel  3  image 
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Figure  10.  Southern  half  of  July  13,  1987  AVHRR  channel  3  image 
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Mgure  1 1.   Subjective  shiptrack  analysis  of  northern  half  of  July  13.  1087  pass 
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Figure  12.  Subjective  shiptrack  analysis  of  southern  half  of  July  13.  1987  pass 
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Figure  13.  Algorithm  Run  A  on  northern  half  of  July  13,  1987  pass. 
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Figure  14.  Algorithm  Run  A  on  southern  half  of  July  13,  1987  pass. 
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Figure  15.  Algorithm  Run  B  on  northern  half  of  July  13,  1987  pass. 
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Figure  16.  Algorithm  Run  B  on  southern  half  of  July  13,  1987  pass. 
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Figure  17.  Algorithm  Run  A  on  Low3  version  of  northern  half  of  July  13,  1987  pass 
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Figure  18.  Algorithm  Run  A  on  Low3  version  of  southern  half  of  July  13,  1987  pass 
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Figure  19.  Algorithm  Run  B  on  Low3  version  of  northern  half  of  July  13,  1987  pass 

61 


Figure  20.  Algorithm  Run  B  on  lx>w3  version  of  southern  half  of  July  13,  1987  pass 
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TABLE  8 

JULY  13,  1987 

SUBJECTIVE  AND  ALGORITHM 

DETERMINED  STATISTICS 

SUBJECTIVE  STATISTICS 

NS-40 

NH  =  23 
ST  =8450 
HL  =  4680 
OA  =8.40 

RUN  A  STATISTICS 

STD  =  28 

HTD  =  21 

NHD=16 
STL  =3215 
SHL  =  2575 

NFD  =  11 

RUN  B  STATISTICS 

STD  =  25 

HID  =18 

NHD=14 

STL  =  2595 

SHL  =  2015 

NFD  =  5 

NS  =  Number  of  ST  subjectively  observed 

NH  =  Number  of  HT  subjectively  observed 

SL  =  Total  length  of  observed  ST 

HL  =  Total  length  of  observed  HT 

OA  =  Total  open  ocean  area  in  km1  x  106 

STD  =  Number  of  ST  objectively  detected 

HID  =  Number  of  HT  objectively  detected 

NHD  =  Number  of  ST  heads  detected 

STL  =  Total  detected  ST  length 

SHL  =  Total  detected  HT  length 

NFD  =  Number  of  false  detections 
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TABLE  9 

JULY  13.  1987  (LOW3) 

SUBJECTIVE  AND  ALGORITHM 

DETERMINED  STATISTICS 

SUBJECTIVE  STATISTICS 


NS  = 

=  40 

mi 

=  23 

ST  = 

8450 

HL  = 

4680 

OA- 

8.40 

RUTS  A  STATISTICS 

STD 

=  25 

HTD 

=  19 

NHD 

=  13 

STL  = 

2645 

SHL  = 

1625 

NFD 

i  =  9 

RUN  B  STATISTICS 

STD  =  20 

HTD  =16 

NHD=11 

STL  =2090 

SHL=1235 

NFD  =  4 

NS      =  Number  of  ST  subjectively  observed 

NH     =  Number  of  HT  subjectively  observed 

SL      =  Total  length  of  observed  ST 

HL      =  Total  length  of  observed  HT 

OA     =  Total  open  ocean  area  in  km2  x  106 

STD     =  Number  of  ST  objectively  detected 

HTD     -  Number  ofHT  objectively  detected 

NHD    =  Number  of  ST  heads  detected 

STL      -  Total  detected  ST  length 

SHL     =  Total  detected  HT  length 

NFD    =  Number  of  false  detections 
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Figure  21.  June  27,  1987  AVHRR  channel  3  image 
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Figure  22.  Subjective  shiptrack  analysis  of  June  27,  1987  pass 
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Figure  23.  Algorithm  Run  A  of  June  27,  1987  pass. 
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figure  24.  Algorithm  Run  B  of  June  27,  1987  pass. 
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TABLE  10 

JUNE  27,  1987 

SUBJECTIVE  AND  ALGORITHM 

DETERMINED  STATISTICS 

SUBJECTIVE  STATISTICS 

NS  =  52 

NH  =  44 
ST- 15620 
HL  =  14400 

OA  =7.32 

RUN  A  STATISTICS 

SID  =  27 

HTD  =  25 

NHD=15 

STL  =3255 

SHL  =  3205 

NFD  =  6 

RUN  B  STATISTICS 

SID  =  27 

HTD  =  24 

NHD=14 

STL  =3035 

SHL  =  2925 

NFD  =  7 

NS  =  Number  of  ST  subjectively  observed 

NH  =  Number  ofHT  subjectively  observed 

SL  =  Total  length  of  observed  ST 

HL  =  Total  length  of  observed  HT 

OA  =  Total  open  ocean  area  in  km2  xlO6 

STD  =  Number  of  ST  objectively  detected 

HTD  =  Number  ofHT  objectively  detected 

NHD  =  Number  of  ST  heads  detected 

STL  =  Total  detected  ST  length 

SHL  =  Total  detected  HT  length 

NFD  =  Number  of  false  detections 
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Figure  25.  Northern  half  of  July  7,  1987  AVHRR  channel  3  image 
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Figure  26.  Southern  half  of  July  7,  1987  AVHRR  channel  3  image 
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Figure  27.  Subjective  shiptraek  analysis  of  northern  half  of  July  7,  1987  pass 
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Figure  28.  Subjective  shiptrack  analysis  of  southern  half  of  July  7,  1987  pass 
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Figure  29.  Algorithm  Rim  A  on  northern  half  of  July  7,  1987  pass. 
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Figure  30.  Algorithm  Run  A  on  southern  half  of  July  7,  1 987  pass. 
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Figure  31.  Algorithm  Run  B  on  northern  half  of  July  7,  1987  pass. 
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Figure  32.  Algorithm  Run  B  on  southern  half  of  July  7,  1987  pass. 
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TABLE  11 

JULY  7,  1987 

SUBJECTIVE  AND  ALGORITHM 

DETERMINED  STATISTICS 

SUBJECTIVE  STATISTICS 

NS=  19 

NH=13 
ST  =  4610 
HL=3640 
OA  =8.35 

RUN  A  STATISTICS 

STD  =  9 

HTD  =  6 

NHD  =  2 

STL  =  970 

SHL  =  840 

NFD  =  14 

RUN  B  STATISTICS 

STD  =  8 

HTD  =  5 

NHD  =  2 
STL  =  940 
SHL  =  810 
NFD  =  12 

NS      =  Number  of  ST  subjectively  observed 

NH     =  Number  of  HT  subjectively  observed 

SL      =  Total  length  of  observed  ST 

HL     =  Total  length  of  observed  HT 

OA     =  Total  open  ocean  area  in  km2x\06 

STD     =  Number  of  ST  objectively  detected 

HTD    =  Number  ofHT  objectively  detected 

NHD    =  Number  of  ST  heads  detected 

STL     =  Total  detected  ST  length 

SHL     =  Total  detected  HT  length 

NFD    =  Number  of  false  detections 
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Figure  33.  Northern  half  of  July  8,  1987  AVHRR  channel  3 
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Figure  34.  Southern  half  of  July  8,  1987  AVHRR  channel  3  image 
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Figure  35.  Subjective  shiptrack  analysis  of  northern  half  of  July  8,  1987  pass 
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Figure  36.  Subjective  shiptrack  analysis  of  southern  half  of  July  8,  1987  pass 
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Figure  37.  Algorithm  Run  A  on  northern  half  of  July  8,  1987  pass. 
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Figure  38.  Algorithm  Run  A  on  southern  half  of  July  8,  1987  pass. 
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Figure  39.  Algorithm  Run  B  on  northern  half  of  July  8,  1987  pass. 
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Figure  40.  Algorithm  Run  B  on  southern  half  of  July  8,  1987  pass. 
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TABLE  12 

JULY  8,  1987 

SUB JECTTVE  AND  ALGORITHM 

DETERMINED  STATISTICS 

SUBJECTIVE  STATISTICS 

NS=16 
NH=13 

ST  =5725 
HL=5130 
OA  =5.55 

RUN  A  STATISTICS 

STD  =  7 

HTD  =  4 

NHD  =  4 
STL  =  650 
SHL  =  300 
NFD=10 

RUN  B  STATISTICS 

STD  =  6 

HTD  =  4 

NHD  =  4 
STL  =  695 
SHL=595 

NFD  =  5 

NS  =  Number  of  ST  subjectively  observed 

NH  =  Number  ofHT  subjectively  observed 

SL  =  Total  length  of  observed  ST 

HL  =  Total  length  of  observed  HT 

OA  =  Total  open  ocean  area  in  km1  x  106 

STD  =  Number  of  ST  objectively  detected 

HTD  =  Number  of  HT  objectively  detected 

NHD  =  Number  of  ST  heads  detected 

STL  =  Total  detected  ST  lenglh 

SHL  =  Total  detected  HT  length 

NFD  =  Number  of  false  detections 
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TABLE  13 

ALGORITHM  PERFORMANCE 

STATISTICS 


RUN  A  SETTINGS 


Run 

SR 

HR 

SL 

ffl, 

SC 

m 

HD 

ED 

13JulA 

72 

91 

38 

55 

72 

28 

70 

1.31 

LowA 

63 

83 

31 

35 

74 

26 

57 

1.07 

27JunA 

52 

55 

19 

20 

79 

21 

32 

0.96 

7JulA 

47 

46 

21 

23 

39 

61 

15 

1.68 

8JulA 

44 

31 

12 

10 

54 

46 

31 

0.90 

Combined 

57 

65 

25 

26 

63 

37 

43 

1.31 

RUN  B  SETTINGS 

13JuIB 

63 

78 

31 

43 

83 

17 

61 

0.60 

LowB 

50 

70 

25 

26 

83 

17 

48 

0.48 

27JunB 

52 

57 

21 

22 

82 

18 

34 

0.82 

7JuB2 

42 

38 

20 

16 

40 

60 

23 

1.44 

8J11JB 

38 

31 

11 

10 

41 

59 

31 

1.80 

Combined 

51 

58 

22 

23 

72 

28 

39 

0.87 

SR  =  *ST  detection  rate 

HR  =  0  STH  detection  rate 

SL  =  ST  length  detection  percentage 

HL  =  STH  length  detection  percentage 

FR  =  False  detection  rate 

SC  =  ST  detection  confidence 

HD  =  Head  detection  rate 

FD  =  False  detections  per  km2  x  106 


*ST  denotes  shiptrack 

0STH  denotes  shiptracks  with  clearly  visible  heads 


88 


Figure  41.  Natural  cloud  feature  that  produced  algorithm  false  detections:  North-south 
aligned  cloud  edge  preferentially  illuminated  by  the  sun  in  the  near-ER  in  a  low  sun  angle 
region  of  the  July  7  pass.  Top  image  is  channel  1.  Bottom  image  is  channel  3. 
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Figure  42.  Natural  cloud  feature  producing  algorithm  false  detections:  Relatively  thin 
cloud  streaks  over  water  near  the  edge  of  the  July  1 3  pass.  Top  image  is  channel  1 . 
Bottom  image  is  channel  3 
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Figure  43.  Natural  cloud  feature  producing  algorithm  false  detections:  Gravity  wave 
interaction  with  marine  boundary  layer.  Top  image  is  channel  1 .  Bottom  image  is 
channel  3 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 

The  goal  of  this  project  was  to  quantitatively  determine  the  performance  of  the  most 
recent  version  of  a  shiptrack  detection  algorithm.  The  statistics  are  prepared  from  the 
author's  subjective  analysis  of  the  four  satellite  passes.  Many  times  during  the  subjective 
analysis,  a  feature  that  possessed  all  the  right  shiptrack  characteristics  in  terms  of  channel 
1 ,  3  and  4  brightness,  gradients  and  temperatures,  was  rejected  simply  because  it  didn't 
look  like  a  shiptrack.  Clearly,  this  subjectivity  must  be  taken  into  account  when 
reviewing  absolute  numbers  describing  the  algorithm's  performance. 

Overall,  the  algorithm  performed  as  designed,  detecting  the  majority  of  the  shiptracks 
without  producing  excessively  high  numbers  of  false  detections.  The  performance 
characteristics  of  the  two  chosen  "optimum"  control  parameter  settings  fluctuated  from 
pass  to  pass,  generally  performing  better  on  those  cases  having  a  large  number  of  bright 
shiptracks  (July  1 3  and  June  27)  than  those  with  less  bright  and  fewer  shiptracks  (July  7 
and  8).  Run  A  settings  consistently  detected  a  higher  number  of  shiptracks  than  Run  B 
settings  but  consistently  produced  a  higher  false  detection  rate. 

The  low3  version  of  the  July  13  case  was  less  successful  than  the  original  channel  3 
version.  In  the  near-IR,  the  low3  image  did  not  show  the  shiptracks  as  well  as  the 
channel  3  image.  The  cause  for  this  difference  is  not  clear  and  deserves  further  study. 
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A.  FALSE  DETECTIONS 

Much  can  be  learned  from  a  closer  examination  of  algorithm  false  detections.  In 
every  case,  of  course,  features  causing  false  detections  fit  the  coded  description  of 
shiptracks.  In  each  case  the  feature  was  subjectively  rejected  as  fitting  into  one  or  more 
of  the  categories  of  naturally  occurring  cloud  line  features.  With  further  research,  it  may 
be  possible  to  find  specific  characteristics  in  common  to  many  of  these  the  features  (but 
not  common  to  shiptracks  in  general)  and  use  characteristics  to  build  specific  filters  into 
the  algorithm  designed  to  reject  these  naturally  occurring  features,  Once  in  place,  these 
filters  would  allow  the  acceptance  parameters  within  the  algorithm  to  be  more  relaxed, 
thus  allowing  more  potential  shiptracks  to  get  through  to  the  filters.  Building  more 
efficient  filters  and  testing  more  potential  shiptrack  path  segments  would  enhance  the 
performance  of  the  algorithm. 

B.  ALGORITHM  MODIFICATIONS 

There  are  many  places  within  the  code  where  empirical  limits  govern  how  shiptracks 
are  defined  and  how  they  are  tested.  One  such  place  is  within  the  subroutine  Pave,  where 
the  shiptrack  path  is  defined  to  be  7  pixels  wide  and  is  compared  to  regions  in  the 
adjacent  cloud  field  as  part  of  the  subroutine's  acceptance  tests.  This  approach  generally 
fails  towards  the  tail  region  of  a  shiptrack  where  the  cloud  line  becomes  significantly 
wider  than  7  pixels  or  near  the  head  where  it  may  be  less  than  the  maximum  resolution  of 
the  image  (1.1  km). 
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An  alternate  approach  to  this  particular  problem  is  to  define  the  shiptrack  path  as  the 
region  within  the  minimum  and  maximum  channel  3  gradients  as  apposed  to  an  arbitrary 
constant  width.  Such  an  approach  would  decrease  the  number  of  tests  needed  in  Pave  to 
one  simple  requirement  that  the  path  be  brighter  than  the  adjacent  cloud  field.  This  idea 
is  presently  in  the  testing  phase  and  looks  promising. 

A  second  proposal  is  increasing  the  maximum  allowable  path  segment  length  to 
approximately  100  km  and  incorporating  variable  Pave,  Gravel  and  Landscape  path 
perpendicular  percentages  based  on  path  segment  length.  This  may  allow  a  greater 
percentage  of  longer  shiptracks  to  be  detected  without  sacrificing  discriminating  tests  on 
the  shorter  features. 

The  continuing  study  of  objective  shiptrack  detection  will  aid  in  the  analysis  of  the 
shiptrack  phenomenon  and  lead  to  a  better  understanding  of  the  modification  of  oceanic 
stratus  clouds. 
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